Streaming media are multimedia that are constantly received by, and normally presented to, an end-user or client while being delivered by a streaming provider or server. Streaming media systems can for example be implemented over telecommunications networks for example using a telecommunications system to stream Internet television.
A development of media streaming is progressive download. Progressive download is a term used to describe the transfer of digital media files from a server to a client, typically using the HTTP protocol, when initiated from a computer. The client or consumer using progressive download can begin playback of the media before the download is completed. The key difference between streaming media and progressive download is in how the digital media data is received and stored by the client or end user device that is accessing the digital media.
A client media player that is capable of progressive download playback relies on meta data located in the header of the file to be intact and a local buffer of the digital media file as it is downloaded from a web server. At the point in which a certain amount of data becomes available to the local playback device, the media player can begin to play the media. This certain amount of buffered data can, for example, be estimated based on the reception bitrate and the bitrate at which media has been encoded into the file. Alternatively, this certain amount of buffer can be embedded into the file by the producer of the content in the encoder settings assuming that a certain reception bitrate is met or exceeded.
The end user experience is similar to streaming media, however the digital file is typically downloaded to a physical drive on the end user's device. For example the digital file is typically stored in the temporary folder of the associated web browser if the digital media was embedded into a web page or to a storage directory that is set in the preferences of the media player used for playback. The digital media file can stutter or stop play back if the rate of play back exceeds the rate at which the file is downloaded. The file can then begin to play again after further download.
The metadata as well as media data in the files intended for progressive download are interleaved in such a manner that media data of different streams is interleaved in the file and the streams are synchronized approximately. Furthermore, metadata is often interleaved with media data so that the initial buffering delay required for receiving the metadata located at the beginning of the file is reduced. An example how the ISO Base Media File Format and its derivative formats can be restricted to be progressively downloadable can be found in the progressive download profile of the 3GPP file format.
However there are several problems associated with conventional progressive downloading.
Firstly conventional progressive downloading clients cannot efficiently play a file having single metadata file for all versions and all the media data in the same file, because the file bitrate is typically excessive compared to the available network throughput. If the media data resides in separate files compared to the metadata, the overhead of receiving the metadata for all versions delays the start of the playback and may cause interruptions and additional buffering during the playback. Moreover, the received metadata file contains references to such versions of the media content that has not been received—hence, the metadata file is not fully compliant.
Secondly the metadata and respective media data of each fragment covering a certain playback range of a presentation and each version (bitrate) of the content resides in their own file. Such chunking of the content to a large set of small files is used in a possible realization of static HTTP streaming. For example, chunking of a content file of duration 20 minutes and with 10 possible representations (5 video bitrates and 2 audio languages) into small content pieces of 1 second, would result in 12000 small files. This constitutes a burden on web servers, which has to deal with such a large amount of small files.
Thirdly conventional progressive downloading clients cannot play files, when one file contains only a fragment.
Fourthly a regular web server operationally connected with a dynamic streaming server executing a command through CGI generally means the invocation of a newly created process. Starting up the process can take up much more time and memory than the actual work of generating the output, especially when the program still needs to be interpreted or compiled. If the command is called often, the resulting workload can quickly overwhelm the web server.
The overhead involved in interpretation can be reduced by using compiled CGI programs, such as those in C/C++, rather than using Perl or other scripting languages. The overhead involved in process creation can be reduced by solutions such as FastCGI, or by running the application code entirely within the webserver using special extension modules. The popular Web servers developed their own extension mechanisms that allow third-party software to run inside the web server itself, e.g. Apache modules, Netscape NSAPI plug-ins, IIS ISAPI plug-ins. However, the use of readily complied CGI programs or a dedicated extension to a web server makes the streaming server solution platform-specific and hence harder to port to another web server and/or operating system platform.
Fifthly current dynamic HTTP streaming servers are specific to a platform and hence harder to port to another operating system platform. The HTTP server protocol stack has to be implemented and the well-tested, scalable, and robust web servers cannot be used.
Furthermore if the server is state-keeping, then its computational complexity is higher than that of a stateless server.
Sixthly with respect to the transport file format currently used the transmitted files are similar to files formatted according to an existing file format used for file playback but current file players cannot be used to play the transport files. The transport file(s) have to be converted to an existing file format used for file playback in the receiving end if they are intended for file playback. The conversion process can be problematic and may not be straightforward.